[レポート] LINT (LINE Improvement for Next Ten years) #linedevday_report

【LINT (LINE Improvement for Next Ten years)】

2019年11月20日（水）・21日（木）にグランドニッコー東京 台場でLINEのデベロッパーカンファレンス「LINE DEVELOPER DAY 2019」が開催されました。

• LINE DEVELOPER DAY 2019

本記事は、セッション「LINT (LINE Improvement for Next Ten years)」をレポートします。

スピーカー

中村 俊介氏 LINE Engineering manager & Software engineer

セッション概要

2011年にローンチした「LINE」は、1つのコミュニケーションアプリとして始まりました。アジアを中心にユーザを獲得しながら成長し、現在は多くの2nd,3rd partiesと連携するプラットフォームとなりました。これまでの技術カンファレンスで共有してきましたように、その裏側では開発者の地道な努力のもと、安定なサービスを継続的に提供できています。しかし一方で、LINEのシステムはプラットフォームとして解決しなければならない様々な技術的負債に直面しています。このセッションでは、LINEのメッセージングコアの基本技術であるクライアント/サーバ間のコネクションや認証、イベントデリバリ、データ同期についてLINEが抱えてきた問題を全体的に紹介します。そして、特にイベントデリバリに焦点を置いて次の10年に向けて我々がどのように改善に挑戦しているか詳細を話します。

スライド

レポート

LINT background

• LINEは2011年にモバイル向けメッセンジャーアプリとしてリリース
• 当初は100万人ユーザーを想定
  • モバイルなのでiPhone/Androidを想定していた
• 開発者のミッション「メッセンジャーとして安定させる」
• リリースしてから、8年経過し「メッセンジャーサービス」から「プラットフォーム」になった
• サービスを安定化するフェーズから「reliability&flexibility」が重要になった
• 実際、8年経過し技術的負債を抱えてきている

reliability

• どんな状況下においても100%稼働
• 実際はそうではない
  • 未読バッチが消えない
  • ブロックした人からメッセージが来る
• バッチが消えない問題など、ユーザーが操作すれば直ることもあるが、システムが対応する必要のある問題もある
  • 泥臭いことをやりながら今の状態を保っている

flexibility

• Payなども増えメッセージ1つ1つの重要性が増してきている
  • メッセージ1つに対するインパクトが大きい

全体のIssueが簡単に解決できない

• 作業しようとすると広範囲
• クライアントとサーバーチームに分かれている
• サーバーもコンポーネント毎にチームが分かれている
• チームごとに優先度の高い仕事をしている
• 組織的な問題を解決するために生まれたのがLINT

LINT

• LINT(LINE Improvment for Next Ten year)
• 4つのイシュー
  • 1.HTTP/2 and Push
  • 2.Event delivery mechanism
  • 3.Authentication Token renewal
  • 4.General setting storage for client/server
• 今日は1と2の2つのIssueに特化して話をする

Event Delivery Core

• メッセージは、以下の構造で定義されている
  • 1:i64 revision
  • 2:OpType type(メッセージタイプなど)
  • 3:Payload paload(メッセージ自体、ユーザーIDなど)
• 各デバイスごとにOparationをフェッチする

LEGY（LINE Event Gateway）

• 内製のreverse proxyサービス
• SPDYベース
• long polling

1.HTTP/2 and Push

• LEGYは標準的なプロトコルじゃない
  • 内製のプロトコル
  • サーバー内部では無駄なリクエストをしている

SPDYtoHTTP/2

• 何が大変なのか
  • レガシーコード化しやすい
  • ドキュメントがない
  • デバイスごとに変更が必要
• HTTP/2ベースにしていく改善を進めている
  • HTTP/2にすることで、標準的なライブラリを使える
• v2のほうから抽象レイヤーを作ってfallbackする対応をしている

Long polling

• サーバープッシュに切り替える
• 無駄なリクエストを減らすことができる

2.Event delivery mechanism

• client/server間の問題
  • グループに参加
  • クライアントは、グループに参加失敗した
  • サーバーはグループに参加されている
  • クライアントに登録されていないグループからのメッセージが来る
• サーバーとクライアントの不整合が目に見えづらい
• 見える化する作業を進行
• しばらくLINEを起動していないユーザー
• 起動するとフェッチオペレーションで同期化する作業が走りユーザーが何もできない
  • シーケンシャルに処理をしているため
• オペレーションは1つのステートマシンで構成しているので、順序を変えられない
• 複数のiPhoneでLINEを使うと顕著にわかる

Another way = Snapshot APIs

• 3種類の方式でデータを同期化できる仕組み
  • 1.Full Sync
  • 2.Auto Repar
  • 3.manual Repaer

Full Sync

• フェッチではなくSyncというAPI
• クライアントが最後に操作したリビジョンを取得
  • LINEをしばらく使ってなかったクライアント（リビジョンの差分が大きい）はFullSyncでの更新が行われる
• 呼んでないメッセージが10件〜100件程度であればフェッチでいける
• revision gapを見て差が大きいものはFullSync
• Full Sync
  • リビジョンの差分が大きい
  • 新規
  • クライアントのデータが壊れている
  • SnapShotAPIを呼んでそれぞれ情報を取得
  • Message
  • UserSetting
  • SocialGraph
  • Group
  • オペレーションとスナップショットAPIを組み合わせて同期化を組み合わせる

Auto Repair

• データ整合性問題があっても、最終的にはサーバーとクライアントを同期化できている
• クライアントとサーバーでデータのダイジェストをお互い交換
• どこに不整合があるかわからない
• ダイジェストを使ってチェックできる仕組み
• 軽いものは1日、重いのは2週間とかの期間で同期を行う

まとめ

LINEがメッセンジャーからプラットフォームになり、様々な開発チームが複雑に絡み合う中で、それぞれのチームの優先順位が異なる中で生まれたのがLINT。次の10年に向けてのLINEをより良くするために、日々過去の技術を改善しているということで、非常に技術的にも、進め方にも共感させていただきました。